Skip to content

Conversation

@ethanuppal
Copy link

@ethanuppal ethanuppal commented Jun 8, 2025

Description & Motivation

I made this at the start of my Intel internship to learn about ROHD components. I have been polishing it up afterward to turn it into a PR.

I added:

  • A bit reversal component on LogicArrays
  • Fixed-point complex arithmetic
  • Really bad FFT with $\log(n)$ butterfly stages etc

Related Issue(s)

Testing

Backwards-compatibility

Is this a breaking change that will not be backwards-compatible? If yes, how so?

Documentation

Does the change require any updates to documentation? If so, where? Are they included?

@ethanuppal ethanuppal changed the title Implement fixed-point fast forier transform Implement fixed-point fast fourier transform Jun 8, 2025
@ethanuppal ethanuppal changed the title Implement fixed-point fast fourier transform Implement fixed-point Fast Fourier Transform Jun 8, 2025
Copy link
Contributor

@mkorbel1 mkorbel1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good start!

@@ -0,0 +1,225 @@
// Copyright (C) 2021-2024 Intel Corporation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try to keep the headers consistent and accurate:

  • Make sure you update copyright years
  • Most files should have some header describing what the file is, and you can put your name as the author for files you create if you wish

See other files or CONTRIBUTING.md for examples

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you add new components/files that should be publicly visible, make sure to export them (e.g. see lib/src/arithmetic/signals/signals.dart, or the appropriate one per-file)

}

Logic _realPart() =>
getRange(0, _fixedPointWidth(signed, integerBits, fractionalBits));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conceptually, the getRange function creates a new module which extracts the requested bits from the original signal and produces an output that results from that operation. Assigning to that output (as you did in some functions above) doesn't make sense and you'll (hopefully) get an error or at least X.

I think a more convenient way to structure a grouping of two FixedPoints would be to create a LogicStructure which contains two FixedPoints as elements. Then they can be individually referenced, assigned, etc. without needing to extract bits each time or manage widths yourself.

class ComplexFixedPoint extends Logic {
final bool signed;

final int integerBits;
Copy link
Contributor

@mkorbel1 mkorbel1 Jun 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for consistency (including with #208), better might be to call *Width


// mux(this[-1], mux(other[-1], ), mux())

FixedPoint.of(sum, signed: signed, m: m + 1, n: n);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks incomplete?

import 'package:rohd/rohd.dart';
import 'package:rohd_hcl/rohd_hcl.dart';

@immutable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think you'll want to implement == and hashCode as well

import 'package:rohd/rohd.dart';
import 'package:rohd_hcl/rohd_hcl.dart';

int bitReverse(int value, int bits) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could make this private (_bitReverse) if this isn't something we want to expose in the library. Alternatively, you could use LogicValue's reversed to do the work (which also then would cover values >64 bits as well)

@ethanuppal
Copy link
Author

ethanuppal commented Jun 9, 2025

Closing in favor of a fully-pipelined floating-point implementation (#210).

@ethanuppal ethanuppal closed this Jun 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants